---
id: unit1
title: 第一章  
---
import img644 from "./img/644.jpeg";
import img640 from "./img/640.jpeg";
import img641 from "./img/641.jpeg";
import img642 from "./img/642.jpeg";
import img643 from "./img/643.jpeg";


## OSI 参考模型  
==========================================

物理层

作用：定义一些电器，机械，过程和规范，如集线器；

PDU(协议数据单元)：bit/比特

设备：集线器HUB;

注意：没有寻址的概念；

==========================================

数据链路层

作用：定义如何格式化数据，支持错误检测；

典型协议：以太网，帧中继（古董级VPN）

PDU：frame（帧）设备：以太网交换机；

备注：交换机通过MAC地址转发数据，逻辑链路控制；

===========================================

网络层

作用：定义一个逻辑的寻址，选择最佳路径传输，路由数据包；

典型协议：IP，IPX，ICMP,ARP(IP->MAC),IARP;

PDU:packet/数据包；

设备：路由器

备注：实现寻址

============================================

传输层：

作用：提供可靠和尽力而为的传输；

典型协议：TCP,UDP,SPX,port(65535个端口),EIGRP,OSPF,

PDU:fragment 段；

无典型设备；

备注：负责网络传输和会话建立；

=============================================

会话层：

作用：控制会话，建立管理终止应用程序会话；

典型协议：NFS, SQL, ASP, PHP, JSP, RSVP(资源源预留协议), windows， 

备注：负责会话建立；

==============================================

表示层：

作用：格式化数据；

典型协议：ASCII, JPEG. PNG, MP3. WAV, AVI, 

备注：可以提供加密服务；

===============================================

应用层：

作用：控制应用程序；

典型协议：telnet, ssh, http, ftp, smtp, rip, BGP, (未完待续)

备注：为应用程序提供网络服务；

================================================

## tcp/ip 协议
先说一下这些协议，在互联网还没普及时，这些协议就已经出来，随着后来数据日渐丰富，协议种类也在累加。

对于我们来说网络世界丰富多彩，对于互联网来说也就是数据根据相应的规则在跑来跑去。（这些规则就是协议）。就像早上你开车到公司，路上遵守交通规则。然后安全抵达公司。就相当于完成了一次信息发送。废话多啦，开始正题！

楼上说的OSI模型是一种接近完美的理论，注意这种模型只出现在教课书里，这种模型是在TCP/IP协议已经成熟之后提出的，可以理解为升级版。但是并没有流行出来，主要有以下几个原因！

1、出现时间较晚。

2、参杂了太多政策的考量，并没有单单从技术角度出发。

3、…………还有几点给忘啦，反正就是没流行起来。

所以网络数据传输是TCP/IP的天下。

TCP/IP协议是一大堆协议的集合，TCP/IP协议分为四层（也就是数据传输一次主要经历以下4个步骤），分别是从上到下为：应用层，传输层，Internet，物理层。

假如你给你的基友发一个消息，数据开始传输，这时数据就要遵循TCP/IP协议啦，你的电脑会做出以下动作，这些动作你是看不到的。

1、应用层先把你的消息进行格式转换,你的消息是文字还是图片，还是成人视频并进行加密等操作交给传输层。（这时的数据单元（单位）是信息）

2、传输层将数据切割成一段一段的，便与传输并往里加上一些标记，比如当前应用的端口号等，交给Internet。（这时的数据单元（单位）是数据流）

3、Internet开始在将数据进行分组，分组头部包含目标地址的IP及一些相关信息交给物理层。（这时的数据单元（单位）是分组）

4、物理层将数据转换为比特流开始查找主机真实物理地址进行校验等操作，校验通过，开始嗖~嗖~嗖~的住目的地跑。（这时的数据单元（单位）是比特）

到达目的地后，对方设备会将上面的顺序反向的操作一遍，最后呈现出来。

个人感觉已经通俗易懂啦！这些东西都都理论知识，属于基础建设。

- http 属于应用层；




## 什么是 HTTPS 协议？

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。「HTTPS 经由 HTTP 进行通信，利用 SSL/TLS 来加密数据包。」 HTTPS 的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

<img src={{ img640 }} />

HTTP 协议采用「明文传输」信息，存在「信息窃听」、「信息篡改」和「信息劫持」的风险，而协议 TLS/SSL 具有「身份验证」、「信息加密」和「完整性校验」的功能，可以避免此类问题发生。

安全层的主要职责就是「对发起的 HTTP 请求的数据进行加密操作」 和 「对接收到的 HTTP 的内容进行解密操作」。

## TLS/SSL 的工作原理

「TLS」全称「安全传输层协议」（Transport Layer Security）及其前身「安全套接层」（Secure Sockets Layer，缩写作「SSL」） 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。

TLS/SSL 的功能实现主要依赖三类基本算法：「散列函数 hash」、「对称加密」、「非对称加密」。这三类算法的作用如下：

- 散列算法用来验证信息的完整性
- 对称加密算法采用协商的秘钥对数据加密
- 641 非对称加密实现身份认证和秘钥协商
  <img src={{ img641 }} />

## 对称加密、非对称加密是什么，有什么区别？

「对称加密和非对称加密是安全传输层里的加密算法」

「对称加密」

- 对称加密的特点是文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥，
  这种方法在密码学中叫做对称加密算法，对称加密算法使用起来简单快捷，密钥较短，且破译困难

  「通信的双⽅都使⽤同⼀个秘钥进⾏加密, 解密。」 ⽐如，两个人事先约定的暗号，就属于对称加密。

<img src={{ img642 }} />

「优点:」

计算量小、加密速度快、加密效率高。

「缺点:」

「在数据传送前，发送方和接收方必须商定好秘钥，然后双方保存好秘钥。」

「如果一方的秘钥被泄露，那么加密信息也就不安全了」

最不安全的地方, 就在于第一开始, 互相约定密钥的时候!!! 传递密钥!

使用场景：本地数据加密、https 通信、网络传输等

「非对称加密」

通信的双方使用不同的秘钥进行加密解密，即秘钥对（私钥 + 公钥）。

特征: 私钥可以解密公钥加密的内容, 公钥可以解密私钥加密的内容

<img src={{ img643 }} />

非对称加密的特点是：

优点：非对称加密与对称加密相比其安全性更好
「缺点：加密和解密花费时间长、速度慢，只适合对少量数据进行加密。」
使用场景：https 会话前期、CA 数字证书、信息加密、登录认证等

## 4. 数字证书是什么？

使用一种 Hash 算法来对公钥和其他信息进行加密，生成一个信息摘要，然后让有公信力的认证中心（简称 CA ）用它的私钥对消息摘要加密，形成签名。最后将原始的信息和签名合在一起，称为「数字证书」。当接收方收到数字证书的时候，先根据原始信息使用同样的 Hash 算法生成一个摘要，然后使用公证处的公钥来对数字证书中的摘要进行解密，最后将解密的摘要和生成的摘要进行对比，就能发现得到的信息是否被更改了。

4.2 数字证书的作用
现在的方法也不一定是安全的，因为没有办法确定得到的公钥就一定是安全的公钥。可能存在一个中间人，截取了对方发给我们的公钥，然后将他自己的公钥发送给我们，当我们使用他的公钥加密后发送的信息，就可以被他用自己的私钥解密。然后他伪装成我们以同样的方法向对方发送信息，这样我们的信息就被窃取了，然而自己还不知道。为了解决这样的问题，可以使用「数字证书」。

4.3 数字签名是什么？
数字签名就是先用 CA 自带的 Hash 算法来计算出证书内容的一个摘要，然后使用 CA 私钥进行加密，组成数字签名。

当别人把他的数字证书发过来时，接收方用同样的算法再次生成摘要，用 CA 公钥解密后得到 CA 生成的摘要，两者进行对比后，就能确定中间是否被人篡改。这样就能最大程度的保证通信的安全了。

5. HTTPS 通信（握手）过程
   HTTPS 的通信过程如下：

客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。  
服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。  
客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。  
服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。  
客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。

6. HTTPS 的优缺点
   HTTPS 的「优点」如下：

使用 HTTPS 协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器；
使用 HTTPS 协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性；
HTTPS 是现行架构下最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本；
HTTPS 的「缺点」如下：

HTTPS 需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂；
HTTPS 协议握手阶段比较费时，增加页面的加载时间；
SSL 证书是收费的，功能越强大的证书费用越高；
HTTPS 连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本；
SSL 证书需要绑定 IP，不能再同一个 IP 上绑定多个域名。 7. 「HTTPS」是如何保证安全的？
结合「对称加密」和「非对称加密」两种加密⽅式，将对称加密的密钥使⽤⾮对称加密的公钥进⾏加密，然后发送出去，接收⽅使⽤私钥进⾏解密得到对称加密的密钥，然后双⽅可以使⽤对称加密来进⾏沟通。

这个时候还需要⼀个安全的「第三⽅颁发证书」（CA），证明身份的身份，防⽌被中间⼈攻击。

为了防止中间人篡改证书，需要用到「数字签名」这个技术

数字签名就是⽤ CA ⾃带的 HASH 算法对证书的内容进⾏ HASH 得到⼀个摘要，再⽤ CA 的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的 Hash 算法,再次⽣成消息摘要，然后⽤ CA 的公钥对数字签名解密,得到 CA 创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。这个时候就能最⼤程度保证通信的安全了。

## 8.HTTP 状态码分别代表什么意思？

| 「类别」 |            「原因」             | 「描述」                   |
| :------: | :-----------------------------: | -------------------------- |
|   1xx    |   Informational(信息性状态码)   | 接受的请求正在处理         |
|   2xx    |       Success(成功状态码)       | 请求正常处理完毕           |
|   3xx    |    Redirection(重定向状态码)    | 需要进行附加操作一完成请求 |
|   4xx    | Client Error (客户端错误状态码) | 服务器无法处理请求         |
|   5xx    | Server Error(服务器错误状态码)  | 服务器处理请求出错         |

「（1）2XX 成功」

200 OK，表示从客户端发来的请求在服务器端被正确处理
201 Created 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立。通常是在POST请求，或者是某些PUT请求之后创建了内容，进行的返回的响应。
202 Accepted 请求服务器已接受，但是尚未处理，不保证完成请求。适合异步任务或者说需要处理时间比较长的请求，避免HTTP链接一直占用。
204 No content，表示请求成功，但响应报文不含实体的主体部分
205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
206 Partial Content，进行的是范围请求，表示服务器已经成功处理了部分GET请求，响应头中会包含获取的内容范围(常用于分段下载)

「（2）3XX 重定向」

301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
302 found，临时性重定向，表示资源临时被分配了新的 URL，支持搜索引擎优化
303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
304 not modified，自从上次请求后，请求的网页内容未修改过。服务器返回此响应时，不会返回网页内容。(「协商缓存」)
307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

「（3）4XX 客户端错误」

400 bad request，请求报文存在语法错误(传参格式不正确)
401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息(没有权限)
403 forbidden，表示对请求资源的访问被服务器拒绝
404 not found，表示在服务器上没有找到请求的资源
408 Request Timeout 客户端请求超时
409 Confict 请求的资源可能引起冲突


「（4）5XX 服务器错误」

500 internal sever error，表示服务器端在执行请求时发生了错误
501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求


## 9. 同样是重定向，「307」，「303」，「302」的区别？

「302」是http1.0的协议状态码，在http1.1版本的时候为了细化302状态码⼜出来了两个303和307。

「303」明确表示客户端应当采⽤get⽅法获取资源，他会把POST请求变为GET请求进⾏重定向。

「307」会遵照浏览器标准，不会从post变为get。


## 10. DNS 协议是什么

「概念」：DNS 是「域名系统」 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。它是一个由分层的 DNS 服务器组成的分布式数据库，是定义了主机如何查询这个分布式数据库的方式的应用层协议。能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

「作用」：将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。


## 11. DNS完整的查询过程

DNS服务器解析域名的过程：

首先会在「浏览器的缓存」中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步   
将请求发送给「本地DNS服务器」，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步   
本地DNS服务器向「根域名服务器」发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址   
本地DNS服务器向「顶级域名服务器」发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址   
本地DNS服务器向「权威域名服务器」发送请求，域名服务器返回对应的结果   
本地DNS服务器将返回结果保存在缓存中，便于下次使用  
本地DNS服务器将返回结果返回给浏览器  


## 简述一下TCP的三次握手

「第一次握手：」 客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。

「第二次握手：」 服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。

「第三次握手：」 当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

## 「TCP什么要三次握手呢？两次不行吗？」

为了确认双方的接收能力和发送能力都正常  
如果是用两次握手，则会出现下面这种情况：  
如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。  


## 14. 简述一下TCP的四次挥手
「第一次挥手：」 若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。

「第二次挥手」：服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。

「第三次挥手」：服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。

「第四次挥手：」 客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。


## 15. TCP「为什么需要四次挥手呢？」

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手。


## 16. TCP粘包是怎么回事，如何处理?

默认情况下, TCP 连接会启⽤「延迟传送算法」 (Nagle 算法), 在数据发送之前缓存他们. 如果短时间有多个数据发送, 会缓冲到⼀起作⼀次发送 (缓冲⼤⼩⻅ socket.bufferSize ), 这样可以减少 IO 消耗提⾼性能.

如果是传输⽂件的话, 那么根本不⽤处理粘包的问题, 来⼀个包拼⼀个包就好了。但是如果是多条消息, 或者是别的⽤途的数据那么就需要处理粘包.

⽽对于处理粘包的问题, 常⻅的解决⽅案有:

「多次发送之前间隔⼀个等待时间」：只需要等上⼀段时间再进⾏下⼀次 send 就好, 适⽤于交互频率特别低的场景. 缺点也很明显, 对于⽐较频繁的场景⽽⾔传输效率实在太低，不过⼏乎不⽤做什么处理.

「关闭 Nagle 算法」：关闭 Nagle 算法, 在 Node.js 中你可以通过 socket.setNoDelay() ⽅法来关闭 Nagle 算法, 让每⼀次 send 都不缓冲直接发送。该⽅法⽐较适⽤于每次发送的数据都⽐较⼤ (但不是⽂件那么⼤), 并且频率不是特别⾼的场景。如果是每次发送的数据量⽐较⼩, 并且频率特别⾼的, 关闭 Nagle 纯属⾃废武功。另外, 该⽅法不适⽤于⽹络较差的情况, 因为 Nagle 算法是在服务端进⾏的包合并情况, 但是如果短时间内客户端的⽹络情况不好, 或者应⽤层由于某些原因不能及时将 TCP 的数据 recv, 就会造成多个包在客户端缓冲从⽽粘包的情况。(如果是在稳定的机房内部通信那么这个概率是⽐较⼩可以选择忽略的)

「进⾏封包/拆包：」 封包/拆包是⽬前业内常⻅的解决⽅案了。即给每个数据包在发送之前, 于其前/后放⼀些有特征的数据, 然后收到数据的时 候根据特征数据分割出来各个数据包。

## 17. token是什么？

token也可以称做「令牌」，一般由 uid+time+sign(签名)+[固定参数] 组成

:::tips

uid: 用户唯一身份标识
time: 当前时间的时间戳
sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库 

:::

- token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中

- token 的认证流程

:::tips

用户登录，成功后服务器返回Token给客户端。
客户端收到数据后保存在客户端
客户端再次访问服务器，将token放入headers中 或者每次的请求 参数中
服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码
:::

- token可以抵抗csrf，cookie+session不行

- session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session

- 客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

## 18. token是怎么加密的

- 需要一个secret（随机数）
- 后端利用secret和加密算法(如：HMAC-SHA256)对payload(如账号密码)生成一个字符串(token)，返回前端
- 前端每次request在header中带上token
- 后端用同样的算法解密

## 19. cookie和token都放在header中，为什么会劫持cookie，不会劫持token

- 「cookie」: 登陆后后端生成一个sessionid放在cookie中返回给客户端, 并且服务端一直记录着这个 sessionid, 客户端以后每次请求都会带上这个sessionid, 服务端通过这个sessionid来验证身份之类的操作。所以别人拿到了cookie就相当于拿到了sessionid ,就可以完全替代你。同时浏览器会自动携带cookie
- token: 同样是登录后服务端返回一个token，客户端保存起来，在以后http请求里手动的加入到请求头里，服务端根据token 进行身份的校验。浏览器不会自动携带token，所以不会劫持 token。

## 20. token过期后，页面如何实现无感刷新?

「什么是无感刷新」

后台返回的token是有时效性的，时间到了，你在交互后台的时候，后台会判断你的token是否过期（安全需要），如果过期了就会逼迫你重新登陆！

「token无感刷新其本质是为了优化用户体验,当token过期时不需要用户跳回登录页重新登录,而是当token失效时,进行拦截,发送刷新token的ajax,获取最新的token进行覆盖,让用户感受不到token已经过期」

「实现无感刷新」

1、后端返回过期时间，前端判断token过期时间,去调用刷新token接口。

缺点：需要后端额外提供一个Token过期时间的字段；使用了本地时间判断，若本地时间篡改，特别是本地时间比服务器时间慢时，拦截会失败。

2、写个定时器，定时刷新Token接口。缺点：浪费资源,消耗性能,不建议采用。

3、在响应拦截器中拦截，判断Token 返回过期后，调用刷新token接口。


## 21. 介绍下304过程

a. 浏览器请求资源时首先命中资源的Expires 和 Cache-Control，Expires 受限于本地时间，如果修改了本地时间，可能会造成缓存失效，可以通过Cache-control: max-age指定最大生命周期，状态仍然返回200，但不会请求数据，在浏览器中能明显看到from cache字样。  
b. 强缓存失效，进入协商缓存阶段，首先验证ETagETag可以保证每一个资源是唯一的，资源变化都会导致ETag变化。服务器根据客户端上送的If-None-Match值来判断是否命中缓存。  
c. 协商缓存Last-Modify/If-Modify-Since阶段，客户端第一次请求资源时，服务服返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间。再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存  




三、浏览器安全

## 1. 有哪些可能引起前端安全的问题?

「跨站脚本」 (Cross-Site Scripting, XSS): ⼀种代码注⼊⽅式, 为了与 CSS 区分所以被称作 XSS。早期常⻅于⽹络论坛, 起因是⽹站没有对⽤户的输⼊进⾏严格的限制, 使得攻击者可以将脚本上传到帖⼦让其他⼈浏览到有恶意脚本的⻚⾯, 其注⼊⽅式很简单包括但不限于 JavaScript / CSS / Flash 等；
「iframe 的滥⽤」: iframe 中的内容是由第三⽅来提供的，默认情况下他们不受控制，他们可以在 iframe 中运⾏ JavaScirpt 脚本、Flash 插件、弹出对话框等等，这可能会破坏前端⽤户体验；
「跨站点请求伪造」（Cross-Site Request Forgeries，CSRF）: 指攻击者通过设置好的陷阱，强制对已完成认证的⽤户进⾏⾮预期的个⼈信息或设定信息等某些状态更新，属于被动攻击
「恶意第三⽅库」: ⽆论是后端服务器应⽤还是前端应⽤开发，绝⼤多数时候都是在借助开发框架和各种类库进⾏快速开发，⼀旦第三⽅库被植⼊恶意代码很容易引起安全问题。

## 2. 网络劫持有哪几种，如何防范？

⽹络劫持分为两种:

（1）「DNS 劫持」: (输⼊京东被强制跳转到淘宝这就属于 dns 劫持)

DNS 强制解析: 通过修改运营商的本地 DNS 记录，来引导⽤户流量到缓存服务器
302 跳转的⽅式: 通过监控⽹络出⼝的流量，分析判断哪些内容是可以进⾏劫持处理的,再对劫持的内存发起 302 跳转的回复，引导⽤户获取内容
（2）「HTTP 劫持」: (访问⾕歌但是⼀直有贪玩蓝⽉的⼴告),由于 http 明⽂传输,运营商会修改你的 http 响应内容(即加⼴告)

DNS 劫持由于涉嫌违法，已经被监管起来，现在很少会有 DNS 劫持，⽽ http 劫持依然⾮常盛⾏，最有效的办法就是全站 HTTPS，将 HTTP 加密，这使得运营商⽆法获取明⽂，就⽆法劫持你的响应内容。

## 3. 进程与线程的概念

从本质上说，进程和线程都是 CPU 工作时间片的一个描述：

进程描述了 CPU 在运行指令及加载和保存上下文所需的时间，放在应用上来说就代表了一个程序。
线程是进程中的更小单位，描述了执行一段指令所需的时间。
「进程是资源分配的最小单位，线程是 CPU 调度的最小单位。」

## 4. 进程和线程的区别

进程可以看做独立应用，线程不能

- 「资源」：进程是 cpu 资源分配的最小单位（是能拥有资源和独立运行的最小单位）；线程是 cpu 调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程）。
- 「通信方面」：线程间可以通过直接共享同一进程中的资源，而进程通信需要借助 进程间通信。
- 「调度」：进程切换比线程切换的开销要大。线程是 CPU 调度的基本单位，线程的切换不会引起进程切换，但某个进程中的线程切换到另一个进程中的线程时，会引起进程切换。
- 「系统开销」：由于创建或撤销进程时，系统都要为之分配或回收资源，如内存、I/O 等，其开销远大于创建或撤销线程时的开销。同理，在进行进程切换时，涉及当前执行进程 CPU 环境还有各种各样状态的保存及新调度进程状态的设置，而线程切换时只需保存和设置少量寄存器内容，开销较小。

## 5. 如何实现浏览器内多个标签页之间的通信?

实现多个标签页之间的通信，本质上都是通过中介者模式来实现的。因为标签页之间没有办法直接通信，因此我们可以找一个中介者，让标签页和中介者进行通信，然后让这个中介者来进行消息的转发。通信方法如下：

「使用 websocket 协议」，因为 websocket 协议可以实现服务器推送，所以服务器就可以用来当做这个中介者。标签页通过向服务器发送数据，然后由服务器向其他标签页推送转发。
「使用 ShareWorker 的方式」，shareWorker 会在页面存在的生命周期内创建一个唯一的线程，并且开启多个页面也只会使用同一个线程。这个时候共享线程就可以充当中介者的角色。标签页间通过共享一个线程，然后通过这个共享的线程来实现数据的交换。
「使用 localStorage 的方式」，我们可以在一个标签页对 localStorage 的变化事件进行监听，然后当另一个标签页修改数据的时候，我们就可以通过这个监听事件来获取到数据。这个时候 localStorage 对象就是充当的中介者的角色。
「使用 postMessage 方法」，如果我们能够获得对应标签页的引用，就可以使用 postMessage 方法，进行通信。

## 6. 为什么需要浏览器缓存？

对于浏览器的缓存，主要针对的是前端的静态资源，在发起请求之后，拉取相应的静态资源，并保存在本地。如果服务器的静态资源没有更新，那么在下次请求的时候，就直接从本地读取即可，如果服务器的静态资源已经更新，那么我们再次请求的时候，就到服务器拉取新的资源，并保存在本地。这样就大大的减少了请求的次数，提高了网站的性能。这就要用到浏览器的缓存策略了。

所谓的「浏览器缓存」指的是浏览器将用户请求过的静态资源，存储到电脑本地磁盘中，当浏览器再次访问时，就可以直接从本地加载，不需要再去服务端请求了。

浏览器缓存的优点
使用浏览器缓存，有以下优点：

- 减少了服务器的负担，提高了网站的性能
- 加快了客户端网页的加载速度
- 减少了多余网络数据传输

## 7. 点击刷新按钮或者按 F5、按 Ctrl+F5 （强制刷新）、地址栏回车有什么区别？

「点击刷新按钮或者按 F5：」 浏览器直接对本地的缓存文件过期，但是会带上 If-Modifed-Since，If-None-Match，这就意味着服务器会对文件检查新鲜度，返回结果可能是 304，也有可能是 200。  
「用户按 Ctrl+F5（强制刷新）：」 浏览器不仅会对本地文件过期，而且不会带上 If-Modifed-Since，If-None-Match，相当于之前从来没有请求过，返回结果是 200。  
「地址栏回车」：浏览器发起请求，按照正常流程，本地检查是否过期，然后服务器检查新鲜度，最后返回内容。

## 8. 浏览器渲染过程中遇到 JS 文件如何处理？

JavaScript 的加载、解析与执行会阻塞文档的解析，也就是说，在构建 DOM 时，HTML 解析器若遇到了 JavaScript，那么它会暂停文档的解析，将控制权移交给 JavaScript 引擎，等 JavaScript 引擎运行完毕，浏览器再从中断的地方恢复继续解析文档。

也就是说，如果想要首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都建议将 script 标签放在 body 标签底部的原因。当然在当下，并不是说 script 标签必须放在底部，因为你可以给 script 标签添加 defer 或者 async 属性。

## 9. 什么是文档的预解析？

Webkit 和 Firefox 都做了这个优化，当执行 JavaScript 脚本时，另一个线程解析剩下的文档，并加载后面需要通过网络加载的资源。这种方式可以使资源并行加载从而使整体速度更快。需要注意的是，预解析并不改变 DOM 树，它将这个工作留给主解析过程，自己只解析外部资源的引用，比如外部脚本、样式表及图片。

## 10. CSS 如何阻塞文档解析？

理论上，既然样式表不改变 DOM 树，也就没有必要停下文档的解析等待它们。然而，存在一个问题，JavaScript 脚本执行时可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析，脚本将得到错误的值，显然这将会导致很多问题。

所以「如果浏览器尚未完成 CSSOM 的下载和构建，而我们却想在此时运行脚本，那么浏览器将延迟 JavaScript 脚本执行和文档的解析，直至其完成 CSSOM 的下载和构建。」 也就是说，在这种情况下，浏览器会先下载和构建 CSSOM，然后再执行 JavaScript，最后再继续文档的解析。

## 11.浏览器本地存储的方式

### Cookie

Cookie 是最早被提出来的本地存储方式，在此之前，服务端是无法判断网络中的两个请求是否是同一用户发起的，为解决这个问题，Cookie 就出现了。「Cookie 的大小只有 4kb」，它是一种纯文本文件，「每次发起 HTTP 请求都会携带 Cookie。」

「Cookie 的特性：」

- Cookie 一旦创建成功，名称就无法修改
- Cookie 是无法跨域名的，也就是说 a 域名和 b 域名下的 cookie 是无法共享的，这也是由 Cookie 的隐私安全性决定的，这样就能够阻止非法获取其他网站的 Cookie
- 每个域名下 Cookie 的数量不能超过 20 个，每个 Cookie 的大小不能超过 4kb
- 有安全问题，如果 Cookie 被拦截了，那就可获得 session 的所有信息，即使加密也于事无补，无需知道 cookie 的意义，只要转发 cookie 就能达到目的
- Cookie 在请求一个新的页面的时候都会被发送过去

「如果需要域名之间跨域共享 Cookie，有两种方法：」

- 使用 Nginx 反向代理
- 在一个站点登陆之后，往其他网站写 Cookie。服务端的 Session 存储到一个节点，Cookie 存储 sessionId

### LocalStorage

LocalStorage 是 HTML5 新引入的特性，由于有的时候我们存储的信息较大，Cookie 就不能满足我们的需求，这时候 LocalStorage 就派上用场了。

「LocalStorage 的优点：」

- 在大小方面，LocalStorage 的大小一般为 5MB，可以储存更多的信息
- LocalStorage 是持久储存，并不会随着页面的关闭而消失，除非主动清理，不然会永久存在
- 仅储存在本地，不像 Cookie 那样每次 HTTP 请求都会被携带

「LocalStorage 的缺点：」

- 存在浏览器兼容问题，IE8 以下版本的浏览器不支持
- 如果浏览器设置为隐私模式，那我们将无法读取到 LocalStorage
- LocalStorage 受到同源策略的限制，即端口、协议、主机地址有任何一个不相同，都不会访问

### SessionStorage

SessionStorage 和 LocalStorage 都是在 HTML5 才提出来的存储方案，SessionStorage 主要用于临时保存同一窗口(或标签页)的数据，刷新页面时不会删除，关闭窗口或标签页之后将会删除这些数据。

「SessionStorage 与 LocalStorage 对比：」

- SessionStorage 和 LocalStorage 都在「本地进行数据存储」；
- SessionStorage 也有同源策略的限制，但是 SessionStorage 有一条更加严格的限制，SessionStorage「只有在同一浏览器的同一窗口下才能够共享」；
- LocalStorage 和 SessionStorage「都不能被爬虫爬取」；

## 12. Cookie、LocalStorage、SessionStorage 区别

「cookie：」 其实最开始是服务器端用于记录用户状态的一种方式，由服务器设置，在客户端存储，然后每次发起同源请求时，发送给服务器端。cookie 最多能存储 4 k 数据，它的生存时间由 expires 属性指定，并且 cookie 只能被同源的页面访问共享。

「sessionStorage：」 html5 提供的一种浏览器本地存储的方法，它借鉴了服务器端 session 的概念，代表的是一次会话中所保存的数据。它一般能够存储 5M 或者更大的数据，它在当前窗口关闭后就失效了，并且 sessionStorage 只能被同一个窗口的同源页面所访问共享。

「localStorage：」 html5 提供的一种浏览器本地存储的方法，它一般也能够存储 5M 或者更大的数据。它和 sessionStorage 不同的是，除非手动删除它，否则它不会失效，并且 localStorage 也只能被同源页面所访问共享。

## 13.什么是同源策略，什么是跨域

「同源策略：protocol（协议）、domain（域名）、port（端口）三者必须一致。」

「同源政策主要限制了三个方面：」

当前域下的 js 脚本不能够访问其他域下的 cookie、localStorage 和 indexDB。
当前域下的 js 脚本不能够操作访问操作其他域下的 DOM。
当前域下 ajax 无法发送跨域请求。
同源政策的目的主要是为了保证用户的信息安全，它只是对 js 脚本的一种限制，并不是对浏览器的限制，对于一般的 img、或者 script 脚本请求都不会有跨域的限制，这是因为这些操作都不会通过响应结果来进行可能出现安全问题的操作。

「什么是跨域」

指的是浏览器不能执行其他网站的脚本，它是由浏览器的同源策略造成的,是浏览器对 javascript 施加的安全限制，防止他人恶意攻击网站

「跨域问题其实就是浏览器的同源策略造成的。」

## 14. 如何解决跨越问题

「CORS」: CORS 需要浏览器和服务器同时支持，整个 CORS 过程都是浏览器完成的，无需用户参与。因此实现「CORS 的关键就是服务器，只要服务器实现了 CORS 请求」，就可以跨源通信了。

「JSONP」
`「jsonp」的原理就是利用<script>标签没有跨域限制，通过<script>标签 src 属性，发送带有 callback 参数的 GET 请求，服务端将接口返回数据拼凑到 callback 函数中，返回给浏览器，浏览器解析执行，从而前端拿到 callback 函数返回的数据`

「优点」

实现简单
兼容性好, 可用于解决主流浏览器的跨域数据访问的问题。
「缺点」

只支持 GET 请求 ( 因为
存在被 XSS 攻击的可能, 缺乏安全性保证
需要服务端配合改造
「postMessage」
postMessage 是 HTML5 XMLHttpRequest Level 2 中的 API，且是为数不多可以跨域操作的 window 属性之一，它可用于解决以下方面的问题：

页面和其打开的新窗口的数据传递
多窗口之间消息传递
页面与嵌套的 iframe 消息传递
上面三个场景的跨域数据传递
用法：postMessage(data,origin)方法接受两个参数：

「data」：html5 规范支持任意基本类型或可复制的对象，但部分浏览器只支持字符串，所以传参时最好用 JSON.stringify()序列化。
「origin」：协议+主机+端口号，也可以设置为"\*"，表示可以传递给任意窗口，如果要指定和当前窗口同源的话设置为"/"。
「Node 中间件代理(proxy 正向代理)(两次跨域)」
实现原理：「同源策略是浏览器需要遵循的标准，而如果是服务器向服务器请求就无需遵循同源策略。」 代理服务器，需要做以下几个步骤：

接受客户端请求 。
将请求 转发给服务器。
拿到服务器 响应 数据。
「nginx 反向代理」
实现原理类似于 Node 中间件代理，需要你搭建一个中转 nginx 服务器，用于转发请求。

使用 nginx 反向代理实现跨域，是最简单的跨域方式。只需要修改 nginx 的配置即可解决跨域问题，支持所有浏览器，支持 session，不需要修改任何代码，并且不会影响服务器性能。

实现思路：通过 nginx 配置一个代理服务器（域名与 domain1 相同，端口不同）做跳板机，反向代理访问 domain2 接口，并且可以顺便修改 cookie 中 domain 信息，方便当前域 cookie 写入，实现跨域登录。

## 15. 正向代理和反向代理的区别

<!-- 「正向代理：」
客户端想获得一个服务器的数据，但是因为种种原因无法直接获取。于是客户端设置了一个代理服务器，并且指定目标服务器，之后代理服务器向目标服务器转交请求并将获得的内容发送给客户端。这样本质上起到了对真实服务器隐藏真实客户端的目的。实现正向代理需要修改客户端，比如修改浏览器配置。

「反向代理：」
服务器为了能够将工作负载分不到多个服务器来提高网站性能 (负载均衡)等目的，当其受到请求后，会首先根据转发规则来确定请求应该被转发到哪个服务器上，然后将请求转发到对应的真实服务器上。这样本质上起到了对客户端隐藏真实服务器的作用。一般使用反向代理后，需要通过修改 DNS 让域名解析到代理服务器 IP，这时浏览器无法察觉到真正服务器的存在，当然也就不需要修改配置了。 -->

与反向代理不同，正向代理是客户端需要主动设置代理服务器来进行访问的，而反向代理是服务器后端设置代理服务器来接受客户端请求并转发到后端服务器。
<img src={{ img644 }} />

## 16. 前端安全了解吗，说一下 XSS 和 CSRF，以及怎么规避

「XSS」：跨域脚本攻击

XSS 攻击指的是跨站脚本攻击，是一种代码注入攻击。攻击者通过在网站注入恶意脚本，使之在用户的浏览器上运行，从而盗取用户的信息如 cookie 等。

XSS 的本质是因为网站没有对恶意代码进行过滤，与正常的代码混合在一起了，浏览器没有办法分辨哪些脚本是可信的，从而导致了恶意代码的执行。

攻击者可以通过这种攻击方式可以进行以下操作：

获取页面的数据，如 DOM、cookie、localStorage；
DOS 攻击，发送合理请求，占用服务器资源，从而使用户无法访问服务器；
破坏页面结构；
流量劫持（将链接指向某网站）；
「防御方法」

可以从浏览器的执行来进行预防，一种是使用纯前端的方式，不用服务器端拼接后返回（不使用服务端渲染）。另一种是对需要插入到 HTML 中的代码做好充分的转义。对于 DOM 型的攻击，主要是前端脚本的不可靠而造成的，对于数据获取渲染和字符串拼接的时候应该对可能出现的恶意代码情况进行判断。

「CSRF」：跨站请求伪造

CSRF 攻击指的是「跨站请求伪造攻击」，攻击者诱导用户进入一个第三方网站，然后该网站向被攻击网站发送跨站请求。如果用户在被攻击网站中保存了登录状态，那么攻击者就可以利用这个登录状态，绕过后台的用户验证，冒充用户向服务器执行一些操作。

CSRF 攻击的「本质是利用 cookie 会在同源请求中携带发送给服务器的特点，以此来实现用户的冒充。」

「CSRF 攻击可以使用以下方法来防护：」

- 「进行同源检测」，服务器根据 http 请求头中 origin 或者 referer 信息来判断请求是否为允许访问的站点，从而对请求进行过滤。
- 「使用 CSRF Token 进行验证」，服务器向用户返回一个随机数 Token ，当网站再次发起请求时，在请求参数中加入服务器端返回的 token ，然后服务器对这个 token 进行验证。
- 「对 Cookie 进行双重验证」，服务器在用户访问网站页面时，向请求域名注入一个 Cookie，内容为随机字符串，然后当用户再次向服务器发送请求的时候，从 cookie 中取出这个字符串，添加到 URL 参数中，然后服务器通过对 cookie 中的数据和参数中的数据进行比较，来进行验证。
- 「在设置 cookie 属性的时候设置 Samesite ，限制 cookie 不能作为被第三方使用」，从而可以避免被攻击者利用。Samesite 一共有两种模式，一种是严格模式，在严格模式下 cookie 在任何情况下都不可能作为第三方 Cookie 使用，在宽松模式下，cookie 可以被请求是 GET 请求，且会发生页面跳转的请求所使用。

什么是中间人攻击？
中间⼈ (Man-in-the-middle attack, MITM) 是指攻击者与通讯的两端分别创建独⽴的联系, 并交换其所收到的数据, 使通讯的两端认为他们正在通过⼀个私密的连接与对⽅直接对话, 但事实上整个会话都被攻击者完全控制。在中间⼈攻击中，攻击者可以拦截通讯双⽅的通话并插⼊新的内容。

攻击过程如下:

- 客户端发送请求到服务端，请求被中间⼈截获
- 服务器向客户端发送公钥
- 中间⼈截获公钥，保留在⾃⼰⼿上。然后⾃⼰⽣成⼀个「伪造的」公钥，发给客户端
- 客户端收到伪造的公钥后，⽣成加密 hash 值发给服务器
- 中间⼈获得加密 hash 值，⽤⾃⼰的私钥解密获得真秘钥,同时⽣成假的加密 hash 值，发给服务器
- 服务器⽤私钥解密获得假密钥,然后加密数据传输给客户端


## 18. 前端如何实现即时通讯？websocket

严格意义上: HTTP 协议只能做到客户端请求服务器, 服务器做出响应, 做不到让服务器主动给客户端推送消息!

「那么如果服务器数据更新了, 想要即时通知到客户端怎么办呢 ? (即时通信需求)」

即时通信需求: 服务器数据一有更新, 希望推送给到浏览器

提问的回答重心:

即时通信有哪些方案?
为什么使用了其中某一个方案! websocket
基于 Web 的前端，存在以下几种可实现即时通讯的方式：

短轮询 (历史方案)

开个定时器, 每隔一段时间发请求 (实时性不强，影响性能)

Comet - ajax 长轮询(历史方案)

发送一个请求, 服务器只要数据不更新, 就一直阻塞 (服务器压力过大)

SSE

(利用了 http 协议, 流数据的传输, 并不是严格意义的双向通信, 无法复用连接)

WebSocket (主流)

性能和效率都高!

## 19. 说一下 websocket

「websocket 是一种网络通信协议」，是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通信的协议，这个对比着 HTTP 协议来说，HTTP 协议是一种无状态的、无连接的、单向的应用层协议，通信请求只能由客户端发起，服务端对请求做出应答处理。

「HTTP 协议无法实现服务器主动向客户端发起消息」，websocket 连接允许客户端和服务器之间进行全双工通信，以便任一方都可以通过建立的连接将数据推送到另一端。websocket 只需要建立一次连接，就可以一直保持连接状态

19.2 什么是轮询
「轮询：隔一段时间进行一次查询或者询问」

轮询分为长轮询和短轮询，长轮询是基于短轮询的一个优化结果。

「短轮询：」

通过客户端定期轮询来询问服务端是否有新的信息产生，如果有则返回，没有就不响应， 缺点：也是显而易见，轮询间隔大了则信息不够实时，轮询间隔过小又会消耗过多的流量，增加服务器的负担。

「长轮询：」

是需要服务端进行更改来进行支持，客户端向服务端发送请求时，如果此时服务端没有新的信息产生，并不立刻返回，而是 Hold 住一段时间等有新的信息或者超时再返回，客户端收到服务器的应答后继续轮询。可以看到长轮询比短轮询可以减少大量无用的请求，并且客户端接收取新消息也会实时不少。减少 http 请求对性能的优化是很有利的，所以他是短轮询上的一个优化 缺点：终归来讲还是一个 http 请求，只是进行了变化而已，而且如果客户端不请求，服务端有数据的话，也会一直累积在那，不能实现实时的双向通信

此时的 webSocket 也就「应需而生」了

## 20. 前端怎么做 SEO 优化

「什么是 SEO」

SEO(Search Engine Optimization)，即搜索引擎优化。SEO 是随着搜索引擎的出现而来的，两者是相互促进，互利共生的关系。SEO 的存在就是为了提升网页在搜索引擎自然搜索结果中的收录数量以及排序位置而做的优化行为。而优化的目的就是为了提升网站在搜索引擎中的权重，增加对搜索引擎的友好度，使得用户在访问网站时能排在前面。

「为什么要做 SEO」

提高网站的权重，增强搜索引擎友好度，以达到提高排名，增加流量，改善（潜在）用户体验，促进销售的作用。

「前端怎么做 SEO 优化」

网站结构布局优化: 尽量简单

- 控制首页链接数量
- 网页层级不要太深
- 控制页面大小, 减少 HTTP 请求, 提高网站的加载速度
- 尽量使用语义化标签
- 利用浏览器缓存
## IP是在哪一层
IP协议属于网络层协议，它是TCP/IP协议族的第四层，位于应用层之上，提供了网络层的服务。

IP协议的主要功能是给不同的设备设置不同的数据格式，使得它们可以在互联网上相互通信。IP协议包括四个部分：

网络地址：IP协议定义了网络中的设备如何相互识别，每个设备都有一个唯一的网络地址。
数据包格式：IP协议定义了数据包的格式，包括如何编码数据、如何封装数据以及如何解码数据。
路由：IP协议提供了路由功能，使得不同的数据包可以按照特定的路径传输。
拥塞控制：IP协议还提供了拥塞控制机制，防止网络拥塞影响网络的正常通信。
通过这些功能，IP协议能够让不同的设备在互联网上进行通信，同时保持网络的稳定和可靠性。

## TCP和UDP区别
TCP和UDP是两种传输层协议，它们在数据传输过程中的主要区别如下：

连接方式：TCP是面向连接的，而UDP是无连接的。TCP在建立连接时需要先建立连接，而UDP不需要。  
可靠性：TCP提供可靠的服务，即通过建立连接和传输数据来确保数据的可靠交付。而UDP则不提供可靠性保证，即不保证数据的可靠交付，通信过程中可能会出现丢包和重传等问题。  
序列化：TCP通过序列化机制将数据转换为字节流，然后通过网络发送。而UDP则不进行序列化，而是直接将数据包装在报文段中发送。  
端口号：TCP使用端口号来标识连接，而UDP则不使用。  
适用场景：TCP主要用于可靠性要求较高的传输，如传输大量数据、需要进行数据校验等。而UDP则适用于对实时性要求较高、数据量较小的传输，如网络游戏、实时视频传输等。  
总之，TCP和UDP在传输层协议中各有优缺点，应根据具体的应用场景选择合适的协议。

## UDP一般用在什么场景
UDP（User Datagram Protocol）一般用于需要快速传输少量数据的场景，因为它不会建立连接，所以传输效率比较高。

UDP的优点在于它不需要建立连接，因此不会存在建立连接时的开销，如握手、同步等操作。此外，UDP也不需要进行流量控制，可以更加灵活地进行数据传输。UDP的缺点在于它的可靠性较差，数据包可能会丢失或重复，因此不适合传输重要数据或需要进行数据校验等需要高可靠性的场景。

在实时应用程序中，UDP通常被用于实时音视频传输、在线游戏等需要实时传输数据的场景。由于UDP的实时性较差，但是它可以比较灵活地进行数据传输，因此在这些应用场景中UDP仍然是一种较为常用的传输协议。

## TCP怎么保证可靠
TCP（传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP通过以下几种方式来保证可靠性：

确认应答：在发送数据后，TCP会等待对端的确认应答，确认应答包括确认序号和确认数据长度。如果对端确认已经收到数据，TCP就会关闭连接；如果对端没有确认，TCP会重新发送数据。这样可以避免数据丢失或重复。
超时重传：当发送方一段时间内没有收到确认应答时，TCP会进行重传，重传的时间间隔取决于超时重传定时器和网络延迟等因素。
流量控制：TCP会根据网络流量自动调整发送速率，避免发送速率过快或过慢，从而保证网络的稳定和可靠性。
拥塞控制：当网络出现拥塞时，TCP会进行拥塞控制，根据网络拥塞程度调整发送速率，防止网络过度拥塞。
快速重传：当TCP收到连续三个相同的确认应答时，会立即重传数据，避免数据丢失。
窗口控制：TCP会利用窗口控制来提高传输速度，在一个窗口大小内，不需要等到确认应答才能发送下一段数据，窗口大小就是无需等待确认而可以继续发送的数据的最大值。
通过以上几种方式，TCP在传输过程中可以保证数据的可靠性和稳定性。


## 浏览器解析到head有个内联的style会停止渲染吗
当浏览器解析到HTML中的`<head>`标签时，它会开始构建文档的内部表示形式（DOM）和样式表的内部表示形式（CSSOM）。浏览器在解析CSS时会遇到内联样式，会将其添加到样式表的内部表示形式中，但并不会因为遇到内联样式而停止渲染。  
因此，即使存在内联样式，浏览器也不会停止渲染页面。相反，它会在解析完整个文档后继续渲染。

## 前端  下载的过程中会停止解析吗
在前端下载过程中，通常不会出现解析停止的情况。前端下载通常是通过响应式网页技术和资源管理器（Resource Manager，简称RM）来实现的。

响应式网页技术：响应式网页技术是一种网页设计技术，可以自动适应不同的设备和屏幕大小，保持网页的显示效果和交互体验。当浏览器访问响应式网页时，浏览器会自动分析网页的结构和内容，并将其呈现在适当的设备上，而不会停止解析。
资源管理器：资源管理器是一种用于管理计算机文件和文件夹的软件。在前端下载过程中，RM负责管理下载资源的链接和存储位置。当资源被下载时，RM会监测文件的大小和位置，并将其存储在合适的位置上，以便在下载完成后，浏览器可以顺利地加载和显示该文件。
断点续传（Download Resume）：有些浏览器支持断点续传功能，这意味着在下载过程中，如果用户暂停了下载，浏览器会自动恢复下载，并从上次停止的位置继续下载。这样可以确保下载过程不会被中断，并且可以在任何时候继续下载。
因此，在前端下载过程中，通常不会出现解析停止的情况，而是会按照预定的策略和方式进行下载，以确保下载过程的顺利和完整。